🎯 What problem does this PR solve?

• finish_reason was hardcoded to "stop" on all chat-category routes, even when generation was cut off by max_tokens (should be "length").
• completion_tokens was counted three different ways: stats helper in /v1/chat/completions, whitespace split in /v1/completions (blocking), SSE-event counter in /v1/completions (streaming). The Responses route had its own inline fallback. All four could diverge for the same generation.
• /v1/videos* endpoints were missing from both the in-repo and marketing-site docs.

📝 How does it solve it?

• drainCompletion(result, onToken?) in adapters/openai/completion-result.ts consumes the SDK result.events stream once and returns { text, toolCalls, stats, stopReason, completionTokens, finishReason }.
• Finish-reason precedence: tool_calls > length > stop. All three chat routes (chat, completions, responses) now use it.
• Responses API: stopReason === "length" maps to status: "incomplete" + incomplete_details.reason: "max_output_tokens"; the streaming path emits response.incomplete instead of response.completed.
• Docs: added /v1/videos* to packages/cli/docs/serve-openai.md and docs/website/content/docs/cli/http-server/index.mdx.

The two other QVAC-19778 follow-up items needed no code change — verified against the current tree:

• Streaming cancellation: cancel bridge re-homed by the Fastify rewrite (QVAC-19179 feat[bc]: rewrite serve HTTP layer on Fastify + Zod #2306); every inference route binds req.on('close') → cancel({ requestId }).
• Route preamble DRY: resolveAndCheckModel() / requireModel() (added in QVAC-19179 feat[bc]: rewrite serve HTTP layer on Fastify + Zod #2306) already centralise the preamble across all routes.

🧪 How was it tested?

• New test/completion-result.test.ts: 20 cases covering eos, length, stopSequence, tool_calls finish-reason branches; stats.generatedTokens vs whitespace-fallback token counting; streaming onToken callback ordering.
• Extended test/responses.test.ts and test/responses-streaming.test.ts: assert status: "incomplete" + incomplete_details on max_tokens truncation.
• New e2e cases in test/e2e.bats against a real loaded LLM: max_tokens: 1 with a long-output prompt, asserting finish_reason == "length" and usage.completion_tokens == 1 for both blocking and streaming paths.
• All 374 CLI unit tests pass (bun run test:unit). Lint and typecheck clean (bun run lint).
• All 134 e2e tests pass (npm run test:e2e, Qwen3-600M). Six max_tokens values bumped from 8–24 → 512 in e2e.bats for tests that asserted finish_reason: "stop": these were too tight for Qwen3's chain-of-thought <think> preamble after the fix correctly started returning "length" on budget exhaustion.

🔌 API Changes

// finish_reason now reflects truncation
{ finish_reason: "length" }  // when max_tokens cuts generation short (was always "stop")

// Responses API — length truncation (blocking)
{ status: "incomplete", incomplete_details: { reason: "max_output_tokens" } }
// Responses API — length truncation (streaming)
{ type: "response.incomplete" }  // was "response.completed"

// completion_tokens: now consistently uses stats.generatedTokens (with whitespace-split fallback)
// across /v1/chat/completions, /v1/completions, and /v1/responses

🔗 Dependencies

Depends on #2484 — SDK must emit stopReason: "length" before the two known-failing e2e tests (94, 95) pass.